Closes #112.

Summary

• IndexManager::add_index replaced an entity's index definition instead of merging, and the agent persisted only the newly-added fields — so registering a second indexed/unique field on one entity (e.g. an email unique constraint then a username unique constraint) silently de-registered the first: its idx/{entity}/{field}/… entries were orphaned, equality/range filters on it quietly fell back to full scans, and rows created afterward were never indexed on it
• add_index now merges fields into the existing definition (an entity's index is the union of every field ever indexed on it, since entries are stored per field)
• the agent computes the merged definition, persists and commits it, then updates the in-memory registry (matching the persist→commit→then-mutate order of the constraint methods, so a failed commit leaves memory and disk consistent)
• uniqueness enforcement was never affected — it runs off a separate keyspace, independent of the index registry; the bug only degraded index acceleration
• cluster mode has its own index path and is unaffected; this also removes the blocker for a correct future narrow purge_stale_index_entries scan to indexed fields #90

Migration: a database created before this fix persisted only the last-registered field, so an earlier field lost to the old bug stays de-registered on upgrade — re-declare it via add index / the unique constraint to re-register and reindex; its orphaned entries are inert and never produce wrong results.

Test plan

• core: add_index merges (not replaces), merged_definition unions without mutating, persist→reload keeps all fields
• agent: a row created after two add_index calls is indexed on the first field too (fails under the old replace bug)
• core 146 + agent constraint 40 suites green, clippy clean
• quorum-reviewed: reindex idempotent/no missed rows, uniqueness independent of index, no caller relied on replace, commit-failure consistency restored